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Abstract 


In  recent  years,  system  modernization  has  received  much  attention  within  the  Department  of 
Defense  (DoD).  Typically,  that  attention  has  focused  on  the  technical  and  acquisition  issues 
associated  with  the  new  system.  Less  attention  has  been  paid  to  the  equally  important  issue  of 
planning  the  migration  from  the  old  system  to  the  new  system. 

This  technical  note  reports  on  the  early  results  of  an  approach  that  is  currently  being  piloted 
to  support  software  migration  planning.  This  approach  focuses  on  deriving  actionable  mini¬ 
plans  for  focus  areas  that  are  identified  in  an  initial  increment  of  an  overall  migration  plan. 
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1  Introduction 


In  recent  years,  system  modernization  has  received  much  attention  within  the  Department  of 
Defense  (DoD).  Typically,  that  attention  has  focused  on  the  technical  and  acquisition  issues 
associated  with  the  new  system.  Less  attention  has  been  paid  to  the  equally  important  issue  of 
migration  planning.  A  migration  plan  is  necessary  to  provide  guidance  on  how  to  phase  out 
the  legacy  system  and  move  to  the  new  system. 

A  good  software  migration  plan  should 

•  clearly  describe  the  approach  for  migrating  users  and  operations  from  the  legacy  system 
to  the  new  system 

•  contain  sufficient  detail  to 

-  verify  that  the  approach  is  complete,  coherent,  and  consistent 

-  validate  that  the  approach  is  on  target 

•  provide  a  basis  for 

-  communication  and  understanding  among  stakeholders 

-  managing  resources  and  staff 

-  managing  the  project  (i.e.,  internal  view  of  the  project) 

-  establishing  the  appropriate  relationships  with  and  commitments  from  stakeholders 

-  establishing  a  framework  under  which  any  related  contract  efforts  can  be  managed 

•  provide  a  means  for  executive  management  to  monitor  the  effort  (i.e.,  external  view  of 
the  project) 

•  reduce  risk  and  increase  the  likelihood  of  a  successful  migration  effort 

This  technical  note  describes  the  initial  results  of  an  approach  to  software  migration  planning 
that  is  currently  being  piloted  in  a  major  DoD  organization.  The  approach  enables  migration 
planning  to  be  managed  proactively.  It  is  an  iterative  approach  that  involves  defining  and 
refining  mini-plans  of  action  and  adding  new  focus  areas  as  circumstances  change  and  the 
effort  progresses.  While  this  note  is  based  on  a  specific  migration  example,  the  approach  is 
also  applicable  to  migration  planning  in  general. 
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2  Background 


A  large  DoD  organization  is  in  the  midst  of  a  multi-year  effort  that  involves  a  migration  from 
a  large  number  of  legacy  systems  to  a  new  consolidated  system  that  will  feature  a  common 
user  interface  with  single-point  access  to  the  system.  The  legacy  systems  will  be  phased  out 
over  several  years  as  different  sets  of  new  functionality  become  available. 

The  initial  draft  of  the  organization’s  migration  plan  identified  the  following  major 
migration-planning  factors: 

•  key  tasks,  roles,  and  responsibilities 

•  current  environment 

•  new  environment 

•  migration  timing  and  prioritization 

•  migration  policies 

•  risk  factors 

That  draft  provided  a  high-level  overview  for  the  overall  migration  effort,  including  the 
selection  of  an  initial  pilot  for  migration.  However,  it  needed  an  additional  level  of  detail  to 
make  it  actionable  and  a  mechanism  for  making  it  a  “living  document”  that  would  evolve 
throughout  the  duration  of  the  migration. 

To  get  to  the  required  level  of  detail,  the  team  from  the  Software  Engineering  Institute  (SEI) 
met  with  the  migration  team  and  prepared  a  set  of  checklists  to  address  salient  migration 
issues  related  to  the  development/migration  cycle.  These  checklists  helped  to  gain  insights  on 
the  current  status  of  the  migration  effort,  how  it  was  being  coordinated  with  the  development 
effort,  and  important  issues  and  problems.  Next,  the  SEI  team  analyzed  the  information  and 
identified  candidate  software  focus  areas  that  appeared  to  be  most  relevant  to  the  program’s 
success.  The  SEI  team  presented  the  candidate  focus  areas  to  the  migration  team.  After 
several  iterations,  both  teams  reached  a  consensus  on  an  initial  set  of  focus  areas  to  pursue  in 
some  detail. 

The  migration  team  identified  a  set  of  associated  activities  for  each  focus  area.  Then  the 
program  manager  assigned  a  team  member  to  each  area  and  asked  that  he  or  she  develop  a 
mini-plan  of  action  for  it. 

Section  3  outlines  the  focus  areas  that  were  identified.  Section  4  presents  a  template  for 
driving  the  focus  areas  to  the  next  level  of  detail  and  producing  a  mini-plan  of  action.  Section 
5  presents  a  model  for  performing  the  refinement  of  the  migration  plan.  It  proposes  a  spiral 
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model  that  starts  with  an  existing  version  of  a  migration  plan  and  successively  refines  the 
plan  for  a  set  of  focus  areas. 
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3  Migration-Planning  Focus  Areas  Defined  by  the 
Prototype  Program 


Any  migration  effort  will  have  a  different  set  of  priorities.  For  the  pilot  program,  the  team 
identified  six  critical  focus  areas  through  the  process  described  in  Section  2. 

The  software  focus  areas  that  we  identified  included 

•  migration  planning  and  management 

•  deployment  and  transition  assistance 

•  database  conversion 

•  customer  relationship  management 

•  management  of  the  legacy  system  interface 

•  customer  training 

We  summarize  these  areas  in  the  following  subsections. 

3.1  Migration  Planning  and  Management 

To  ensure  success,  the  migration  effort  needs  to  be  actively  managed.  The  mini-plans  provide 
some  structure  for  tracking  the  program  on  a  continuous  basis  and  are  refined  continuously  to 
ensure  their  currency.  This  continuous  refinement  enables  the  migration  plan  to  be  a  living 
document  and  not  simply  a  document  that  represents  a  check  mark  on  a  list  of  planned 
deliverables. 

The  high-level  activities  for  migration  planning  and  management  include 

•  Refine  the  migration  plan. 

•  Assign  the  necessary  roles  and  responsibilities. 

•  Identify,  plan,  and  budget  for  needed  resources. 

•  Track  and  document  the  migration’s  progress. 

•  Take  corrective  action,  as  needed,  to  reduce  risk. 

•  Coordinate  the  migration  effort  across  focus  areas. 

•  Improve  the  migration  process  based  on  lessons  learned. 

•  Continually  evaluate  the  migration  plan  for  completeness  and  update  it  as  necessary. 
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•  Maintain  a  liaison  with  customer  organizations. 


3.2  Deployment  and  Transition  Assistance 

Because  the  cutover  to  a  new  system  involves  substantially  more  effort  than  merely  turning 
off  the  old  system  and  turning  on  the  new  system,  a  set  of  tasks  is  required  to  enable  smooth 
deployment.  These  tasks  involve  identifying  legacy  systems  and  customer  dependencies, 
mapping  new  capabilities  to  legacy  customers,  developing  cutoff  criteria,  and  finally 
performing  the  actual  cutover. 

The  high-level  activities  for  deployment  and  transition  assistance  include 

•  Identify  the  resources  (both  hardware  and  software)  needed  to  deploy  the  new  system. 

•  Identify  where  those  resources  will  come  from. 

•  Identify  the  parties  responsible  for  deploying  and  sustaining  those  resources. 

•  Develop  guidance  for  preparing  the  site  and  keeping  the  customer  informed. 

•  Develop  an  approach  for  supporting  both  the  old  and  new  systems  during  the  test  period. 

•  Develop  criteria  for  legacy  system  cutoff. 

•  Identify  and  prioritize  cutover  dates  for  the  legacy  system. 

•  Identify  any  customer  dependencies  on  the  legacy  system. 

•  Map  new  capabilities  to  support  legacy  system  customers: 

-  Identify  needed  high-level  capabilities. 

-  Validate  when  the  new  system  will  support  those  capabilities. 

-  Work  with  the  customers  and  assist  them  in  developing  their  own  transition  plan  to 
ensure  buy-in  and  commitment. 

•  Perform  customer  familiarization  exercises: 

-  Obtain  insight  into  potential  “show-stoppers,”  oversights,  and  problem  areas. 

-  Incorporate  lessons  learned  from  initial  rollouts  of  the  migrated  system  to  make  the 
remaining  migration  effort  more  efficient  and  cost  effective. 

•  Provide  technical  assistance  to  customers  to  help  them  fully  transition  to  the  new  system. 

•  Track  the  cutoff  criteria  and  validate  criteria  satisfaction. 

•  Cut  off  the  legacy  system. 


3.3  Database  Conversion 

Database  migration  is  particularly  important  in  information  systems.  When  migration 
involves  conversion  to  a  different  database  or  the  consolidation  of  multiple  databases,  the 
possibility  of  data  inconsistencies  is  high.  For  this  particular  system,  a  large  number  of 
databases  from  different  legacy  systems  were  consolidated. 
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The  high-level  activities  for  database  conversion  include 

•  Identify  the  volume  of  data  to  be  converted. 

•  Identify  the  business  rules  that  impact  the  data  conversion. 

•  Identify  schema  differences  between  the  new  and  old  systems  and  their  impact  on  the 
conversion. 

•  Analyze  the  work  required  for  data  cleanup  and  develop  an  approach  for  it. 

•  Identify  the  software  utilities  needed  to  assist  in  data  conversion. 

•  Convert  the  databases. 

•  Document  the  process  and  results  of  the  data  conversion. 


3.4  Customer  Relationship  Management 

The  consolidated  system  will  have  a  large  and  diverse  set  of  stakeholders.  Different  user 
communities  have  vastly  different  degrees  of  dependency  on  the  existing  systems  as  well  as 
different  understandings  of  the  planned  changes  and  the  relationship  of  those  changes  to  their 
work.  Different  user  communities  will  be  migrating  to  the  new  system  at  different  times  over 
the  next  several  years.  The  success  of  the  system  update  is  highly  dependent  on  acceptance 
by  these  diverse  communities.  As  a  result,  plans  for  customer  relationship  management  are 
critical  to  the  program’s  success. 

The  high-level  activities  for  customer  relationship  management  include 

•  Identify  any  potential  mandates  that  customers  will  need  to  follow. 

•  Inform  customers  of  new  releases  and  capabilities. 

•  Establish  mechanisms  for  customer  feedback. 

•  Formalize  help-desk  procedures  and  policies. 

•  Inform  customers  about  available  training  and  when  it’s  being  offered. 

•  Inform  customers  about  the  data  conversion  activities  and  when  they  are  scheduled. 

•  Inform  customers  about  the  status  of  legacy  system  interfaces  and  how  changes  to  the 
system  may  affect  those  interfaces. 

•  Identify  the  scope  and  extent  of  testing  to  ensure  that  the  new  system  will  be  adequate.  To 
do  so,  perform 

-  trial  testing  and 

-  production  testing 

•  Establish  mechanisms  for  handling  new  customer  requirements. 
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3.5  Management  of  the  Legacy  System  Interface 

This  migration  effort  is  complex  not  only  because  of  the  number  of  systems  being 
consolidated,  but  also  because  of  the  large  number  of  external  systems  that  depend  on  it.  Its 
outputs  will  be  used  by  other  systems  across  the  DoD  organization.  Because  the  system  is 
being  designed  to  a  modified  set  of  requirements,  a  number  of  interface  issues  need  to  be 
resolved — determining  which  interfaces  are  required,  resolving  interface  requirements  in  a 
timely  manner,  and  predicting  the  effects  of  changed  interfaces  on  customers. 

The  high-level  activities  for  legacy  system  interface  management  include 

•  Identify  the  legacy  systems  that  will  require  interfaces. 

•  Coordinate  plans  with  owners  of  legacy  systems. 

•  Identify  system  interfaces  that  have  to  be  carried  forward. 

•  Map  interfaces  to  planned  system  releases. 

•  Identify  any  customer  dependencies. 

•  Prioritize  interface  needs  and  coordinate  them  with  development. 


3.6  Customer  Training 

Each  new  release  of  the  system  will  support  a  new  set  of  users.  Because  of  the  diverse  user 
population,  each  set  of  users  has  a  different  set  of  training  needs.  Users  who  require  extensive 
interaction  with  the  system  for  complex  tasks  will  require  classroom  training  in  small  groups. 
Other  users  who  have  a  more  casual  need  for  the  system  may  require  less  intensive  training. 
Training  needs  to  be  synchronized  with  system  releases  and  the  availability  of  new  system 
functionality. 

The  high-level  activities  for  customer  training  include 

•  Scope  the  training  and  plan  it  to  coordinate  with  system  releases: 

-  Identify  the  training  needed  to  support  customers. 

-  Identify  when  training  will  be  needed. 

•  Identify  the  types  of  training  materials  needed. 

•  Develop  training  materials  including 

-  online  training  aids 

-  customer  training  courses 

•  Identify  who  will  conduct  the  training. 

•  Provide  guidance  for  the  trainers. 

•  Pilot  the  training  with  the  selected  trainers  and  then  evaluate  the  adequacy  of  both  the 
training  and  the  trainers. 
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4  Template  for  Moving  to  the  Next  Level  of  Detail 


The  focus  areas  that  were  identified  in  Section  3  enabled  the  program  manager  to  take  the 
first  step  in  actively  managing  the  migration-planning  effort.  For  each  focus  area,  a 
responsible  person  was  designated  to  develop  a  mini-plan  of  action  down  to  additional  levels 
of  detail.  The  mini-plans  need  to  answer  the  following  questions: 


•  What  needs  to  be  done? 

•  Who  is  going  to  do  it? 

•  How  will  it  be  done? 

•  How  do  we  make  sure  that  it  is  done  satisfactorily? 

The  general  structure  for  developing  a  mini-plan  is  shown  in  Figure  1. 


Cost,  Schedule, 
and  Resources 

Deliverables 


Figure  1:  Basic  Structure  fora  Mini-Plan 

Each  mini-plan  is  being  developed  according  to  the  following  template: 

•  focus  area  goal 

•  entry  criteria 

•  work  breakdown  structure  (WBS)  for  activities 

•  deliverables  (products  and  services) 

•  roles  and  responsibilities 

•  cost,  schedule,  and  resources 

•  artifacts  and  metrics  for  tracking  progress 

•  exit  criteria 
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5  Evolution  and  Refinement  of  the  Migration  Plan 


The  approach  that  we  have  outlined  takes  an  active  and  dynamic  view  of  migration  planning, 
which  is  a  continuous  effort  that  begins  with  the  first  increment  of  the  migration  plan.  The 
overall  process  for  migration  plan  refinement  is  illustrated  in  Figure  2. 


The  first  increment  of  the  plan  identifies  the  primary  issues  and  concerns.  Successive 
iterations  add  more  substance  and  make  the  plan  actionable  and  manageable.  Each  iteration 
provides  more  elaboration  in  the  form  of  detailed  mini-plans  of  action  for  a  set  of  focus  areas 
that  are  most  relevant  to  the  project  (e.g.,  high-priority  areas).  At  any  point  in  time,  the 
migration  plan  can  be  viewed  as  the  sum  of  the  mini-plans  of  action. 


The  relationship  of  the  focus  areas  and  mini-plans  to  a  particular  iteration  of  the  overarching 
migration  plan  is  shown  in  Figure  3.  As  the  mini-plans  are  executed,  progress  is  evaluated 
and  the  migration  plan  is  refined  and  updated. 
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•  focus  area  goal 

•  tasks  &  deliverables 

•  estimate  of  needed  resources 

•  roles  &  responsibilities 

Figure  3:  Relationship  of  Focus  Areas  and  Mini-Plans  to  a  Planning  Iteration 

Regular  status  reports  for  each  mini-plan  are  developed  using  the  following  outline: 

1 .  Focus  Area  Title 

2.  Goal  of  Focus  Area 

3.  WBS  for  Activities 

4.  Status  of  Effort  (By  Task) 

•  technical  progress  (since  last  status  update) 

•  current  status  of  deliverables 

•  cost,  schedule,  and  resources 

5.  Issues  and  Problems 

•  unresolved  issues  or  technical  problems  (e.g.,  delays  and  deficiencies) 

•  cost,  schedule,  and  resource  implications 

•  dependencies  or  impact  on  other  focus  areas 

•  corrective  action 

6.  Objectives  for  Next  Review 

•  items  to  be  completed 

•  problems  and  issues  to  be  resolved 
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6  Conclusion 


This  technical  note  has  reported  on  an  approach  that  is  currently  being  piloted  to  support 
migration  planning.  This  approach  focuses  on  deriving  actionable  mini-plans  for  focus  areas 
that  are  identified  in  an  initial  increment  of  a  migration  plan. 

This  note  describes  an  initial  round  of  migration  planning.  In  subsequent  iterations,  some  of 
the  mini-plans  may  be  found  to  be  incomplete.  An  important  purpose  of  the  iterative 
approach  is  to  improve  the  mini-plans  as  more  information  is  obtained. 

This  iterative  approach  enables  the  migration  planning  to  be  managed  proactively  and 
involves  refining  the  mini-plans  of  action  and  adding  new  focus  areas  as  circumstances 
change  and  the  effort  progresses.  It  allows  a  program  manager  to  obtain  a  “big  picture”  view 
of  the  high-level  software  migration  activities  and  to  understand  and  manage  the  details  that 
need  to  be  addressed  to  achieve  a  successful  outcome.  The  continuous  planning  activity  also 
surfaces  risks  in  an  organic  way,  so  they  can  be  dealt  with  effectively. 

While  this  note  is  based  on  a  specific  migration  example,  the  approach  is  also  applicable  to 
migration  planning  in  general. 
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